import re
def prompt (des,topology,history,context):

    prefix = f'''
# 系统描述
   当前服务种的service包含：adservice，cartservice，checkoutservice，currencyservice，emailservice，frontend，paymentservice，productcatalogservice，recommendationservice，shippingservice
   各个service的描述关系如下:

```mermaid
graph TD
    User((User)) --> frontend[frontend]
    frontend --> ad[ad]
    frontend --> recommendation[recommendation]
    frontend --> productcatalog[productcatalog]
    frontend --> cart[cart]
    frontend --> checkout[checkout]
    recommendation --> productcatalog
    ad --> tidb[tidb]
    productcatalog -->tidb
    tidb --> tidbtidb[tidb-tidb]
    tidb --> tidbtikv[tidb-tikv]
    tidb --> tidbpd[tidb-pd]
    cart --> RedisCache[(Redis cache)]
    checkout --> payment[payment]
    checkout --> email[email]
    checkout --> shipping[shipping]
    checkout --> currency[currency]
    checkout --> productcatalog
    frontend --> shipping
    frontend --> currency
```

   当前系统的服务与节点的映射关系为:

   {topology}
   除此之外，当前节点中还存在k8s-master1、k8s-master2、k8s-master3，作为k8s的管理节点。


# 基本处理逻辑
  ## 基本的处理逻辑应该为:
  1、检查全量日志，分析是否有错误service信息，然后检查trace日志，根据trace给出的调用错误信息，检查相应的service、pod等信息。
  2、如果log和trace 都没有相关日志，那需要按照调用关系，**依次**检查各个service是否有异常。
  3、如果service没有异常，依次检查Pod和node信息，检查是否存在异常。
  ## 按照层级依次检查：
  1、先查 Service 层，通过验证配置、端点状态和转发规则，确认请求入口是否正常，锁定是否为服务路由或负载均衡问题。
  2、再聚焦 Pod 层，检查运行状态、日志与健康探针，结合调度事件分析，定位是否为容器应用故障或资源配置问题。
  3、最后排查 Node 层，通过监控节点资源、系统状态和运行时日志，确认是否因节点异常（如资源耗尽、网络故障）引发上层问题。
  4、请注意，**资源利用率类指标只有>70%才有可能被判断为异常，否则不作为显著依据**
  5、如果当前的服务调用路径没有显著的故障定位或者依据，那么从头开始检查下一个调用路径
  ## 数据说明
  1、采用markdown 表格的形式给出了各个指标的统计数据（只给出具有显著差异的指标，没给出的默认差异较小）
  2、统计数据包括故障前(before)、故障中(abnormal)、故障后(after)的指标

# 定义的方法如下
  LogSearch():检查总体的服务日志情况，该日志应该为总的日志信息
  TraceAnalysis():检查总体的调用链情况，能够挖掘出潜在的日志问题等
  LoadMetrics_allservice():检查所有service的性能指标，包括报错次数、rrt时长等信息
  LoadMetrics_allnode():检查所有node的异常情况，包括资源利用率等
  LoadMetrics_node(node):根据node 查看对应的资源利用率等信息,在明确异常的node情况下调用此函数,给出此函数的时候需要给出对应的node名称
  LoadMetrics_full_service(service):检查某个service的错误，包括对应的service的报错次数、rrt时长等信息,给出该函数同时需要给出对应的service名称
  LoadMetrics_service_pod(service):根据service 查看对应的pod信息,在明确异常的service情况下调用此函数，以明确对应的pod的报错次数、rrt时长等信息,通常在确定某个service存在异常后查看其下的各个pod情况,LoadMetrics_service_pod(cartservice)
  LoadMetrics_pod():根据pod查看对应的资源利用率信息等,通常在明确异常的pod情况下调用此函数,给出此函数的时候需要给出对应的pod名称
  Loadtidb():检查tidb日志
# 问题描述
  用户给出的问题为：
  {des}
# 历史交互信息
    '''

    suffix = '''

# 任务描述
  首先对当前的内容进行总结,请注意，
  - 总结内容需要完整保留异常关键服务或节点信息，如 service 名称（如 "checkoutservice"）、pod 名称（如 "frontend-0"）、或 node 名称（如 "node-3"）等不同层级的组件名称,
  - 总结内容需要完整保留异常关键指标信息，包括查到的error信息或者给出的markdown指标统计表格中的字段名称，如"node_network_transmit_bytes_total", "node_network_transmit_packets_total"等 
  - 总结的内容应该为"{节点或服务} 的 {指标名称以及对应的列名} 发生异常，具体体现在{原因}",或者"{节点、服务}发生异常"
  - 严格按照反馈的内容和历史交互信息进行总结，**禁止出现不在上下文的内容，禁止编造任何指标**
  
  
  并请判断，如果能够定位出根因（必须按照service->pod->infra层层去查）,直到给出根因说明，按照如下指令给出结果，并附上简要说明：
  - 如果需要调用方法(注意，不需要推理原因,不超过3个,且历史已经调用过的方法不能再重复调用)，则给出
    METHOD:需要调用的方法名称
  - 如果能够判断新增可能存在故障的service，则按照如下格式分条给出：
    SERVICE:存在故障的service:故障原因
  - 如果能够判断新增可能存在故障的node，则按照如下格式分条给出：
    NODE:存在故障的node:故障原因
  - 经过查询service、pod、资源层级原因后，如果确定能够定位到根因,请务必保证定位的完整性，请给出如下标记,否则禁止输出任何含有GOCHA的内容：
    GOCHA:根因
  
  !!!! 等下，在给出GOCHA根因结果之前，再反思下是否对可能存在异常的service、pod、node都检查过了吗？现在的根因就是真实的根因吗？
      '''
    
    if history == '':
        return [prefix , context, suffix]
    else:
        return [history, context, suffix]

def gen_result(history,uuid):
    return '''
# 任务说明
根据对故障的分析日志，重新整合故障定位的路径，并按照格式要求生成符合要求的json字符串

# 格式要求与样例
## 格式要求
json字符串的字段说明如下：

| 字段名         | 类型       | 是否必须 | 说明                                                         |
| :------------- | :--------- | :------- | :----------------------------------------------------------- |
| uuid           | string     | 是       | 该条返回结果所对应的故障案例的uuid                            |
| component      | string     | 是       | **根因**组件的名称，每条样本只评估一个根因组件，若提交多个组件，仅评估 JSON 中首个出现的 component 字段，类型需为 string。 |
| reason         | string     | 是       | 故障发生的原因或类型，尽可能简短表达;其中如果涉及metric关键的指标名字,必须与交互记录中给出的markdown表格中的列名称完全一致，例如cpu_usage_rate不能写为cpu usage rate等，大小写也要保持完全一致！如果涉及日志，也要跟日志关键字保持完全一致!|
| reasoning_trace | object[]   | 是       | 完整推理轨迹，包含每步 action/observation 等，尽可能简短表达|


### reasoing_trace 字段说明
#### 基础格式
    "reasoning_trace" 为包含多个 step 对象的数组，每个对象应包含以下字段：
    step：整数，表示推理步骤编号（从 1 开始）；
    action：字符串，描述该步调用或操作；
    observation：字符串，描述该步观察到的结果，尽可能简短表达
    所有字段名建议使用 snake_case 命名风格，避免大小写混用。

#### 关键步骤
    **reasoning_trace 只给出与故障相关的、能够体现异常的关键推理步骤**

#### 关键信息
    在推理步骤中，需要体现关键的定位信息,具体来说，每个故障的标签包含三类关键信息：
- metric 关键信息：包含一些关键的指标名字,其必须与交互记录中给出的markdown表格中的列名称完全一致，例如cpu_usage_rate不能写为cpu usage rate等，大小写也要保持完全一致！
- log 关键信息：包含日志检索行为，并出现一些关键的日志中的关键信息
- trace 关键信息，包含关键的一些调用链条中的故障实例，如checkoutservice等。

### 字段取值约束
    component 字段可以是service、pod、node等，对service、pod、node的名称进行了限制，以保证组件准确性:
    - service的名称只能从如下范围取值："adservice","cartservice","currencyservice","productcatalogservice","checkoutservice","recommendationservice","shippingservice","emailservice","paymentservice","tidb-pd","tidb-tidb","tidb-tikv" 
    - node的名称只能从如下范围取值："aiops-k8s-01","aiops-k8s-02","aiops-k8s-03","aiops-k8s-04","aiops-k8s-05","aiops-k8s-06","aiops-k8s-07","aiops-k8s-08","k8s-master1","k8s-master2","k8s-master3"
    - pod的名称只能从如下范围取值："adservice-0","adservice-1","adservice-2","cartservice-0","cartservice-1","cartservice-2","currencyservice-0","currencyservice-1","currencyservice-2","productcatalogservice-0","productcatalogservice-1","productcatalogservice-2","checkoutservice-0","checkoutservice-1","checkoutservice-2","recommendationservice-0","recommendationservice-1","recommendationservice-2","shippingservice-0","shippingservice-1","shippingservice-2","emailservice-0","emailservice-1","emailservice-2","paymentservice-0","paymentservice-1","paymentservice-2","tidb-pd-0","tidb-tidb-0","tidb-tikv-0"

## 样例
   样例如下：
    {
      "uuid": "33c11d00-2",
      "component": "checkoutservice",
      "reason": "disk IO overload",
      "reasoning_trace": [
        {
          "step": 1,
          "action": "LoadMetrics(checkoutservice)",
          "observation": "disk_read_latency spike"
        },
        {
          "step": 2,
          "action": "TraceAnalysis('frontend -> checkoutservice')",
          "observation": "checkoutservice self-loop spans"
        },
        {
          "step": 3,
          "action": "LogSearch(checkoutservice)",
          "observation": "IOError in 3 logs"
        }
      ]
    }

# 生成流程：
  1、首先根据给出的系统拓扑图、服务调用关系和分析历史，对可能的根因组件、原因以及关键步骤进行分析
  2、按照要求生成json字符串，需要注意的是要以```json...的方式生成，并且生成的内容需要能够被json.loads()解析。

# 分析日志
  以下为故障定位历史轨迹\n'''+f'''{re.sub(r'(^#)|( +#)','##',history)}

# uuid 
uuid为：
{uuid}

请按照要求最终的json字符串：
    '''


def describe_table(table,threshold='', graph = False):

    return f'''
#任务
  请对如下指标表每列指标进行总结，体现m各个指标在异常发生前、异常时间范围和异常发生后的变化情况。
# 数据说明
  1、采用markdown 表格的形式给出了各个指标的统计数据（只给出具有显著差异的指标，没给出的默认差异较小）
  2、统计数据包括故障前(before)、故障中(abnormal)、故障后(after)的指标
  3、请注意，根据指标具体含义，按照异常前、中、后的相对变化情况,只给出具有明显变化以及反应系统异常的指标
  4、只给出显著异常指标分析即可，不需要进行异常分析和总结、下一步计划等

  {'## 其中资源利用率异常值的参考阈值为：' if threshold != '' else ''}
  {threshold}

  {'## 当前系统的拓扑图如下：' + GRAPH if graph == True else ''}

 请如下表格进行总结：
  {table}
'''


